The present invention relates to object-oriented programming. In particular, the present invention relates to identifying attributes of programming objects.
In object-oriented programming, an object is a set of programming instructions that supports one or more methods and/or has one or more properties. A method in an object can be called by instantiating the object (loading the object into memory) and then making a call to the method exposed by the object. A property of an object can be set by instantiating the object and then setting the property.
In some programming environments, multiple objects may expose the same method but may work in different ways. At times, these differences can be significant and an application that wants to invoke the method may want to know how the object will behave before it instantiates the object.
To allow for this, some object-oriented systems provide lists of attributes for objects that have been registered with the system. In particular, the Component Object Model (COM) uses a technique known as Component Categories to maintain a list of object attributes in the local registry. This list can be queried before a COM object is instantiated to determine if the object meets a set of attributes.
Although the Component Categories technique is useful, it has several limitations. First, it relies on the attributes being statically present on a local computer. As a result, COM objects must have their attributes stored on each local machine, resulting in redundant sets of data. In addition, object classes that are made available dynamically or that have their attributes stored outside the local machine cannot be found using component categories.
Second, when searching Component Categories, it is difficult to find objects with desirable but not mandatory attributes. Under Component Categories, each of the search criteria is considered mandatory. If an object does not meet the search criteria, it is not returned. Thus, optional criteria cannot be placed in a first search for objects.
Because of this, an object or application performing a search must do several search iterations to find objects with optional attributes. In particular, the searching application must perform a first search for required attributes, then perform separate searches for each optional attribute.
Lastly, the Component Categories technique does not integrate well with systems that change the behavior or attributes of objects after the objects have been instantiated. In many programming environments, objects are written in a general fashion to support a set of basic methods but the manner in which they support them is dependent on their data source. For example, a text-to-speech object can be written to support the basic methods involved in converting text into speech while the sound of the voice, for example male or female, can be set by selecting a data source that contains the attributes of the voice. If one data source is used with the text-to-speech object, a male voice is heard, if a different data source is used with the same text-to-speech object a female voice is heard.
These types of systems do not work well with Component Categories because a single object listed in the Component Categories cannot have conflicting parameterizations. Taking the example above, the text-to-speech object cannot have an attribute for “gender” set to both “male” and “female”.
Because of this, programmers that want to use Component Categories with such adaptable objects have had to generate different objects for each different combination of attributes. Thus, instead of creating and registering one COM object, programmers must create and register a separate COM object for each set of attributes that they want to support for the object.